Benefits of Using SwitchKit TEP to Integrate a Voice Browser

Excel and Vocalocity have developed an interface that allows enhanced speech capabilities to be deployed on an Excel Converged Services Platform (CSP). That interface is the SwitchKit Telephony Extension Point (TEP). It integrates Vocalocity’s Voice Browser with the Excel Converged Services Platform (CSP). By using the TEP, SwitchKit application developers reduce their development cycle significantly. See also the CSP VoiceXML Platform Implementation Guide.

The TEP is a library that is loaded by the Vocalocity Operating System (VocalOS), where the voice browser resides, and uses SwitchKit (SK) API as the native API. The TEP provides event and function mapping between the SwitchKit API and the VocalOS. For example, when a VXML script needs to play an announcement to one of the CSP channels, a request from the VocalOS is sent to the TEP where it is converted into SK API (PlayFileStart, in this case) and then sent to the switch.

From SwitchKit’s perspective, the TEP is simply an application that is connected to the Low Level Communicator (LLC). The TEP does not directly handle inbound or outbound calls from the CSP. The call signaling functions must be performed by another SwitchKit application besides the TEP. Keeping the call processing outside of the TEP provides greater flexibility to the total solution. With this architecture, our application partners can easily integrate their existing application or create a new one and not be bound to specific call handling.

In this document, the SwitchKit application that handles the call signaling is referred to as the Call Processing Application (CP App.) The CP App and TEP communicate with one another via the LLC using a SwitchKit API message, InterAppMsg (IAM). This document provides the format of a set of IAMs that are defined for this purpose, and shows their placement in various call flows.

The TEP will not perform any media handling of a call until it is told to do so by a CP App — sending a specially formatted IAM. This initial IAM will have a parameter such as called number or calling number that will ultimately determine the web server Uniform Resource Locator (URL) of the desired VXML script. Just before sending the initial IAM, the CP App should issue a sk_monitorChannel. This will allow the CP App to see what actions are being taken on the channel by the TEP.

So from the earlier example, if the CP App is monitoring the channel, it will receive a copy (echo) of the original PlayFileStart message sent by the TEP to the LLC once a switch response is received. This echo will be the same as the originally sent message except the sequence number field will actually indicate the ack status from the switch for the request.

The CP App does not relinquish LLC channel ownership of calls routed to the TEP. Since switch initiated messages are routed to the owning application, the TEP also issues a sk_monitorChannel command of calls it is told to handle. This causes a copy of switch-initiated messages to also be sent to the TEP. So when CallProcessingEvent messages are generated from the action of the earlier example, these messages are sent to the CP APP and the TEP.